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This  paper  presents  a  methodology  to  extend  the  guidance  functionalities  of  Commercial  Off-The-Shelf 
autopilots  currently  available  for  Unmanned  Aircraft  Systems  (UAS).  Providing  that  most  autopilots  only 
support  elemental  waypoint-based  guidance,  this  technique  allows  the  aircraft  to  follow  leg-based  flight 
plans  without  needing  to  modify  the  internal  control  algorithms  of  the  autopilot.  It  is  discussed  how 
to  provide  Direct  to  Fix,  Track  to  Fix  and  Hold  to  Fix  path  terminators  (along  with  Fly-Over  and  Fly- 
By  waypoints)  to  basic  autopilots  able  to  natively  execute  only  a  limited  set  of  legs.  Preliminary  results 
show  the  feasibility  of  the  proposal  with  flight  simulations  that  used  a  flexible  and  reconfigurable  UAS 
architecture  specifically  designed  to  avoid  dependencies  with  a  single  or  particular  autopilot  solution. 

©  2011  Elsevier  Masson  SAS.  All  rights  reserved. 


1.  Introduction 

Unmanned  Aircraft  Systems  (UAS)  are,  at  present,  mainly  de¬ 
signed  for  military  missions  and  very  few  civil  applications  have 
been  developed  so  far  because  of  the  lack  of  an  appropriate  regu¬ 
lation  framework  concerning  their  certification,  airworthiness  and 
operations.  An  important  consequence  is  that  the  development  of 
UAS  has  always  been  highly  dependent  on  the  mission  and  the 
flight  scenario.  Thus,  very  specific  and  non-flexible  systems  exist 
nowadays  to  control  the  desired  flight  plan,  the  UAS  mission,  the 
sensor  activation/configuration,  the  data  storage,  etc.  This  fact  may 
delay  and  increase  the  implementation  costs  (and  risk)  of  a  new 
UAS  application.  The  core  of  a  UAS  is  probably  the  autopilot  and, 
in  order  to  develop  all  necessary  mission  avionics  on  top  of  it,  it  is 
essential  to  understand  how  this  device  works,  what  kind  of  inputs 
supports  and  what  are  its  capabilities. 

There  are  a  considerable  amount  of  Commercial  Off-The-Shelf 
(COTS)  autopilots  designed  for  UAS  (refer  for  instance  to  the  sur¬ 
vey  done  in  [2]).  A  well-known  drawback  regarding  this  technology 
is  that  the  flight  plan  definition  is  composed  by  just  a  collection 
of  statically  defined  waypoints  (or  hand-manipulated  by  the  UAS 
operator),  which  are  flown  in  sequence.  Using  a  basic  list  of  way- 
points  as  the  mechanism  for  flight  planning  specification  has  sev¬ 
eral  important  limitations,  such  as  the  difficulty  to  specify  complex 
trajectories  (needed  for  most  of  the  UAS  typical  missions),  the  lack 
of  support  for  specifying  repetitive  or  conditional  behaviour  in  the 
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flight  plan,  etc.  To  address  these  limitations,  in  [8,6]  a  new  flight 
plan  specification  language  has  been  proposed  that  uses  higher 
level  constructs,  with  richer  semantics,  and  which  enables  the  UAS 
flight  to  be  adapted  to  the  circumstances  encountered  during  the 
mission. 

Besides  basic  trajectories,  the  flight  plan  specification  supports 
constructs  for  conditional  and  iterative  behaviour  together  with 
mission-oriented  area  scanning  and  other  built-in  patterns.  The 
flight  plan  submitted  to  the  UAS  contains  a  nominal  path  that  can 
be  modified  in  real-time  by  updating  a  number  of  specific  param¬ 
eters.  Moreover,  the  flight  plan  can  be  accompanied  by  alternatives 
to  respond  to  emergency  situations  as  well  as  specific  procedures 
for  approach  and  departure  operations.  The  details  of  this  flight 
plan  specification  language  are  found  in  [8],  which  also  describes 
the  overall  architecture  of  the  system  with  a  special  emphasis  on 
the  software  components  involved  in  the  execution  of  the  flight 
plan.  These  software  components  run  on  embedded  hardware  in¬ 
stalled  on-board  the  UAS.  Additionally,  the  human  machine  in¬ 
terfaces  required  to  fully  exploit  the  new  dynamic  characteristics 
offered  by  the  flight  plan  language  are  detailed  in  [6].  The  afore¬ 
mentioned  references,  however,  do  not  go  into  detail  regarding  the 
translation  mechanism  used  to  generate  waypoints  for  the  differ¬ 
ent  flight  plan  primitives.  This  article  provides  insights  on  how 
this  translation  process  takes  place  and  shows  how  the  proposed 
methodology  can  be  used  to  implement  primitives  found  in  the 
flight  plan  specification  language  on  top  of  autopilots  with  differ¬ 
ent  navigation  capabilities. 

Current  COTS  autopilots  for  UAS  do  not  support  any  of  these  ca¬ 
pabilities  and  the  required  guidance  functionalities.  Based  on  Area 
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Fig.  1.  Characteristic  magnitudes  of  the  four  legs  (waypoint+path  terminator)  considered  in  this  paper. 


Navigation  (RNAV),1  our  flight  plan  specification  language  proposes 
the  leg  as  main  flight  planning  component.  A  leg  determines  not 
only  a  destination  point,  but  also  the  trajectory  that  the  aircraft 
should  follow  in  order  to  reach  it.  Since  most  UAS  autopilots  only 
provide  elemental  waypoint-based  guidance,  a  method  for  trans¬ 
lating  flight  plan  legs  to  a  sequence  of  waypoints  which  can  be 
correctly  interpreted  by  the  autopilot  is  needed.  This  paper  focuses 
on  the  computations  required  to  transform  RNAV  leg-based  guid¬ 
ance  primitives  into  sequences  of  “elemental  waypoints”,  and  how 
the  proposed  methodology  can  be  used  to  implement  primitives 
found  in  the  flight  plan  specification  language. 

It  should  be  noted  that  this  paper  is  not  proposing  a  new  path 
planning  technique,  used  for  example  in  highly  constrained  envi¬ 
ronments  (see  [5]);  but  a  way  to  enhance  existing  COTS  autopilots 
with  an  extra  set  of  RNAV  legs.  Thence,  the  safe  and  appropriate 
design  of  the  flight  plan  is  out  of  the  scope  of  this  paper,  since 
it  is  assumed  to  be  compliant  with  RNAV  standards  and  current 
regulations  regarding  aircraft  procedure  design  criteria  [4].  Thus, 
the  proposed  methodology  creates  a  list  of  autopilot-compatible 
waypoints  by  erasing  the  original  ones  in  the  flight  plan  and/or 
by  adding  some  extra  synthetic  waypoints  which  can  be  executed 
by  the  considered  autopilot.  Since  commercial  autopilots  are  of¬ 
fered  as  closed  systems,  this  strategy  allows  to  extend  the  autopilot 
capabilities  without  needing  to  modify  its  internal  control  algo¬ 
rithms.  In  particular,  this  paper  describes  how  to  provide  new 
RNAV  leg-based  functionalities  to  three  hypothetical  COTS  systems 
which  are  able  to  execute  only  one  type  of  waypoint  and  leg.  Sec¬ 
tion  2  of  this  paper  presents  the  implemented  functionalities  while 
some  preliminary  simulation  results  are  shown  in  Section  3. 


1  A  method  of  navigation  that  allows  to  fly  routes  that  can  be  defined  between  ar¬ 
bitrary  waypoints  within  the  coverage  of  a  network  of  navigation  beacons  or  within 
the  limits  of  a  self  contained  positioning  system,  or  a  combination  of  both. 


2.  Implemented  functionalities 

In  manned  aviation,  RNAV  procedures  have  been  progressively 
introduced  in  the  last  two  decades,  along  with  Flight  Management 
Systems  (FMS)  on-board  the  aircraft.  In  order  to  translate  RNAV 
leg-based  procedures  into  a  suitable  code  for  these  systems,  the  in¬ 
dustry  has  developed  the  Path  and  Termination  concept,  along  with 
a  database  standard  published  by  Aeronautical  Radio,  Inc.  (ARINC) 
[1].  This  standard  details  how  databases  for  FMS  are  to  be  coded. 
Path  terminators  provide  the  means  to  translate  the  text  and  the 
routes  depicted  on  the  navigation  plates  used  by  pilots  into  FMS 
readable  code. 

In  short,  a  Path  terminator  defines  a  specific  flight  path  and  a 
specific  type  of  termination  for  each  leg.  Leg  types  are  identified 
by  a  two  letter  code  that  describes  the  path  (e.g.,  heading,  course, 
track,  etc.)  and  the  termination  condition  (e.g.,  the  path  terminates 
at  a  fix,  an  altitude,  a  given  distance  to  a  radiobeacon,  a  given  time, 
etc.).  Besides  path  terminators,  two  basic  waypoint  types  exist  in 
RNAV:  Fly-Over  (FO)  and  Fly-By  (FB)  waypoints.  The  former  en¬ 
tail  the  actual  over-fly  of  the  waypoint,  before  heading  to  the  next 
waypoint.  On  the  other  hand,  in  an  FB  waypoint  the  aircraft  starts 
turning  before  reaching  the  waypoint  in  such  a  way  that  it  is  ob¬ 
tained  a  turning  arc  tangential  with  the  two  flight  segments  that 
precede  and  follow  the  waypoint. 

For  example,  Figs.  1(a)  and  1(b)  display  two  different  path  ter¬ 
minators  following  a  Fly-Over  waypoint.  In  Fig.  1(a)  a  Direct  to 
Fix  (DF)  path  terminator  is  executed,  meaning  that  the  aircraft 
will  head  direct  to  the  next  waypoint  after  completing  the  turn, 
regardless  of  its  actual  position.  On  the  other  hand,  Fig.  1(b)  dis¬ 
plays  a  Track  to  Fix  (TF)  path  terminator  where,  after  over-flying  the 
turning  waypoint,  the  aircraft  joins  the  track  existing  between  the 
over-flown  waypoint  and  the  next  one.  In  Fig.  1(c)  a  TF  path  ter- 
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Table  1 

Required  modifications  on  the  nominal  flight  plan  in  order  to  enhance  a  system  capable  of  executing  only  one  type  of  leg  (waypoint+path  terminator). 


System  capability 

Implemented  leg 

Delete  original  WP? 

Extra  virtual  WPs 

Coordinates  of  the  extra  waypoints  (WPs) 

FO+DF 

FO+TF 

No 

WP1 

*1  =  L\  +  L2  +  L3  +  L4  —  L5  cos  p 

yi  =L5  sin  ft 

FB+TF 

Yes 

WP1 

X\  =  —L'  ■  COST p 

yi  =  —V  ■  sin 

FO+HF 

No 

WP1 

X\  =  —L" 

yi  =  -2  R 

FO+TF 

FO+DF 

No 

WP1 

X\  =  L\  +  L2  + 13 

yi  =  (L  —  Li  -L2-L3)  tanp 

FB+TF 

Yes 

WP1 

X\  =  —L'  ■  COST p 

y  1  =  —L'  •  sin 

WP2 

X2=V 

y2  =  o 

FO+HF 

No 

WP1 

x\  =  0 

yi  =  -2  R 

WP2 

*2  =  -L" 

y2  =  -2  R 

WP3 

x3  =  —L" 

Y3  =  0 

FB+TF 

FO+DF 

Yes 

WP1 

X\  =  D  cos  0 

yi  =  D  sini fr 

FO+TF 

Yes 

WP1 

Xi  =  D  cos  0 

yi  =  D  sin0 

WP2 

X2  —  t\  +  L2  +  L3  +  L4 

yi  =  o 

WP1 

*1  =  R 

yi  =0 

FO+HF 

Yes 

WP2 

X2  =  R 

y2  =  —2  R 

WP3 

x3  =  -(L"  +  R) 

y3  =  -2  R 

WP4 

x4  =  ~(L"  +  R) 

y4  =  o 

minator  is  shown  after  a  Fly-By  type  waypoint,  while  in  Fig.  1(d)  a 
Hold  to  Fix  (HF)  follows  the  Fly-Over  waypoint. 

There  exist  up  to  23  different  path  terminators,  even  if  most  of 
the  FMS  can  usually  execute  a  small  set  of  them  [3].  This  paper 
describes  how  to  provide  new  RNAV  functionalities  to  three  hypo¬ 
thetical  systems  which  are  able  to  execute  only  one  type  of  leg 
(waypoint+path  terminator).  These  three  studied  systems  are: 

•  FO+DF:  System  capable  of  Fly-Over  (FO)  waypoints  followed 
by  Direct  to  Fix  (DF)  path  terminators. 

•  FO+TF:  System  capable  of  Fly-Over  (FO)  waypoints  followed 
by  Track  to  Fix  (TF)  path  terminators. 

•  FB+TF:  System  capable  of  Fly-By  (FB)  waypoints  followed  by 
Track  to  Fix  (TF)  path  terminators. 

Among  all  RNAV  path  terminators,  DF,  TF  and  HF  are  the  most 
basic  and  common  ones,  allowing  an  autopilot  to  execute  a  wide 
range  of  basic  RNAV  procedures  already  published  in  many  coun¬ 
tries  [3].  In  this  paper,  the  following  legs  will  be  implemented  for 
each  of  the  three  previous  considered  systems:  FO+DF,  FO+TF, 
FB+TF  and  FO+HF.2  In  Fig.  1,  the  nominal  trajectory  and  asso¬ 
ciated  magnitudes  of  these  four  transitions,  when  considering  a 
course  change  of  angle  0,  are  shown. 

Assuming  an  aircraft  performing  a  coordinated  turn  at  a  con¬ 
stant  bank  angle  0  and  with  no  altitude  change,  the  nominal  turn 
radius  is  given  by: 


gtan0 

where  v  is  the  aircraft  airspeed,  while  g  ~  9.81  ms-1  is  the  ac¬ 
celeration  of  the  gravity.  The  bank  angle  is  an  aircraft  dependent 
parameter,  taking  in  general,  values  around  0  =  25°  in  manned  air¬ 
craft  [7].  For  UAS,  however,  higher  values  can  be  foreseen. 

For  an  FO+DF  transition  (Fig.  1(a)),  the  aircraft  turns  in  such 
a  way  that  its  new  heading  leads  directly  to  the  next  waypoint. 
Therefore,  the  interception  angle  for  this  waypoint  is  a  function  of 
the  course  change  (0),  the  length  of  the  leg  (L)  and  the  turn  radius 
(R).  The  analytical  computation  of  this  angle  /1(0,  F,  R)  is  given  in 
Appendix  A  of  this  paper.  Conversely,  for  an  FO+TF  transition  (see 
Fig.  1(b)),  this  interception  angle  is  fixed  beforehand  to  a  typical 
value  of  p  =  30°  [4]. 


2  Note  that  the  combination  FB+DF  is  senseless  and  that  the  HF  path  terminator 
must  always  follow  an  FO  waypoint  [1]. 


From  Fig.  1  and  after  some  basic  trigonometric  analysis,  some 
characteristic  length  magnitudes  describing  each  transition  can  be 
computed  as  follows: 


Li=Rsin0  I2  =  R  cos  0  tan 


L3  =  R  sin  ft  (  1 


COS0 

cos  p 


L4  =  R 


cos * 


sinfi 


u  _ cos  t  \ 

\  cosfi  ) 


L5  =  Ri  tan  - 

2 


0 

L  =  R  tan  — 


D  =  R  tan 


m 


(2) 


The  methodology  proposed  in  this  paper  to  enhance  the  basic 
autopilot  capabilities  is  by  adding  extra  virtual  waypoints  and/or  by 
eliminating  the  original  waypoint  to/from  the  original  flight  plan. 
This  modification  of  the  nominal  list  of  waypoint  is  computed  in 
a  way  that  the  trajectory  obtained  when  executing  the  new  flight 
plan  with  a  basic  autopilot,  matches  with  the  trajectory  we  would 
obtain  had  the  original  flight  plan  been  executed  with  an  autopilot 
capable  to  perform  natively  the  required  waypoint  and  path  termi¬ 
nator  types. 

According  to  this  methodology,  Table  1  summarises  all  the 
modifications  required  on  the  nominal  flight  plan  in  order  to  vir¬ 
tually  provide  the  autopilot  with  the  four  new  leg  capabilities 
(FO+TF,  FO+DF,  FB+TF  and  FO+HF).  Thus,  for  each  new  imple¬ 
mented  leg,  the  table  shows  the  cases  when  the  original  waypoint 
should  be  deleted  from  the  flight  plan  and  how  many  extra  vir¬ 
tual  waypoints  are  needed  to  code.  For  each  extra  waypoint,  its 
location  is  given  in  a  Cartesian  coordinate  system  (x,  y),  centred  at 
the  nominal  waypoint  of  study  and  with  the  x  axis  aligned  with 
the  line  joining  this  waypoint  with  the  following  waypoint  in  the 
flight  plan  sequence.  In  Figs.  2,  3  and  4,  the  location  of  these  new 
waypoints  is  shown  graphically  for  each  of  the  new  implemented 
leg.  These  figures  correspond  to  autopilots  capable  to  execute  only 
FO+DF,  FO+TF  and  FB+TF  transitions,  respectively. 


3.  Preliminary  implementation  and  simulation  infrastructure 

The  implementation  of  the  described  methods  forms  part  of  an 
on-going  effort  by  the  authors  to  build  a  UAS  architecture  able  to 
execute  leg-based  procedures  that  is  not  locked-in  to  a  single  au¬ 
topilot  solution.  Fig.  5  displays  the  simulation  environment  that 
has  been  set  up  to  test  the  presented  approach.  The  Flight  Plan 
Manager  (FPMa)  and  the  Virtual  Autopilot  System  (VAS)  are  soft¬ 
ware  components,  on-board  the  UAS  platform,  that  communicate 
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(b)  Enabling  a  FB+TF  ' 
Fig.  2.  Enhancing  an  autopilot  capable  to  execute  only  FO+DF  legs. 


(b)  Enabling  a  FB+TF  leg 
Fig.  3.  Enhancing  an  autopilot  capable  to  execute  only  FO+TF  legs. 


(a)  Enabling  a  FO+DF  leg 

Fig.  4.  Enhancing  an  autopilot  capable  to  execute  only  FB+TF  legs. 


with  each  other  through  a  Local  Area  Network.  A  document  de¬ 
scribing  the  flight  plan  using  our  leg-based  specification  language 
is  submitted  to  the  FPMa  to  perform  its  execution.  This  component, 
by  using  the  above  presented  equations,  computes  the  sequence 
of  waypoints  that  the  flight  plan  translates  into,  and  sends  them 
to  the  VAS;  which  in  turn,  provides  a  hardware-independent  in¬ 
terface  to  interact  with  the  autopilot.  As  shown  in  the  figure,  the 
implementation  of  the  VAS  is  divided  into  two  blocks:  one  fac¬ 
ing  the  network  and  another  one  facing  the  UAS  platform.  While 
the  former  is  always  the  same,  the  latter  depends  on  the  actual 
autopilot  system  and  implements  the  communication  protocols  re¬ 
quired  by  the  autopilot.  Therefore,  as  illustrated,  one  could  have  an 
implementation  that  is  able  to  operate  with  a  given  commercial 
autopilot  and  another  one  for  interacting  with  a  particular  flight 


simulator.  The  installed  autopilot  system  is  ultimately  responsible 
for  implementing  the  guidance  and  control  loops. 

The  presented  simulations  have  been  performed  by  using  the 
FlightGear  open  source  flight  simulator.3  Fig.  6(a)  displays  the  re¬ 
sults  of  an  example  simulation  when  the  VAS  interacts  with  an 
autopilot  capable  of  executing  only  FO  waypoints  followed  by  DF 
path  terminators.  The  figure  displays  the  flight  plan  legs  as  straight 
lines  connecting  different  waypoints,  which  can  be  either  FB  or  FO. 
The  actual  list  of  waypoints  generated  by  the  FPMa  is  drawn  on 
top,  together  with  the  actual  flight  trajectory  obtained  after  the 
simulation.  Leg  A  is  a  TF  leg  that  connects  an  FO  waypoint  (2) 


3  See  http://www.flightgear.org. 
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Fig.  5.  Simulation  environment. 


(a)  Enhancing  an  autopilot  capable  to  exe- 


(b)  Enhancing  an  autopilot  capable  to  exe¬ 


cute  only  FO+DF  legs 


cute  only  FB+TF  legs 


Fig.  6.  Simulation  results  using  systems  with  different  basic  leg  capabilities. 


to  an  FB  destination  waypoint  (5).  Since  the  simulated  autopilot 
deals  natively  with  FO  waypoints,  no  special  treatment  is  required 
for  waypoint  (2).  An  extra  waypoint  (3)  is  needed  to  intercept  the 
track  and  the  original  destination  waypoint  (5)  is  moved  to  a  new 
position  (4)  to  actually  perform  a  fly-by  manoeuvre.  Leg  B  is  also  a 
TF  leg  and  as  in  leg  A,  the  destination  waypoint  (7)  is  moved  to  a 
new  position  (6)  in  order  to  perform  a  fly-by.  With  the  destination 
waypoint  (8)  of  leg  C  being  an  FO  followed  by  a  DF  leg,  no  spe¬ 
cial  waypoint  transformations  are  required  for  the  rest  of  the  flight 
plan. 

A  different  flight  plan  and  its  execution  are  shown  in  Fig.  6(b) 
to  demonstrate  how  the  system  deals  with  an  autopilot  that  sup¬ 
ports  only  FB  waypoints  followed  by  TF  path  terminators.  Leg  A  of 
this  flight  plan  is  also  a  TF  leg  that  starts  with  an  FO  waypoint  (2). 
Since  FO  waypoints  are  not  natively  supported,  waypoint  2  needs 
to  be  removed  and  two  extra  FB  waypoints  are  added  (3  and  4). 
Legs  B  and  C  are  DF  legs  that  start  with  an  FO  waypoint  (respec¬ 
tively,  waypoints  5  and  7)  and  in  both  cases,  the  aircraft  follows 
the  track  between  a  displaced  initial  waypoint  (6  and  8)  and  the 
leg’s  destination. 

4.  Conclusion 

Area  Navigation,  coupled  with  other  technologies,  is  enabling 
a  move  towards  trajectory-based  operations.  Bringing  trajectory- 
based  capabilities  to  UAS  will  make  them  easier  to  integrate  into 
non-segregated  airspace  and  also  increase  their  ability  to  perform 
missions  which  require  complex  trajectories  to  be  flown  (such  as 
loitering  over  certain  areas).  Most  of  current  commercially  avail¬ 


able  autopilot  solutions,  however,  only  provide  waypoint-based 
guidance.  Moreover,  due  to  the  closed  nature  of  these  systems,  it 
is  not  possible  to  modify  them  in  order  to  implement  leg-based 
guidance.  A  possible  solution  to  enhance  such  basic  autopilots  is  to 
conveniently  modify  the  original  flight  plan,  as  it  has  been  shown 
in  this  paper. 

Since  the  presented  simulations  have  been  carried  out  without 
considering  wind  conditions,  arguably,  the  results  only  confirm  the 
correctness  of  the  analytical  equations  proposed  and  their  imple¬ 
mentation.  Nevertheless,  the  simulation  infrastructure  provides  a 
valuable  test-bed  for  further  developments  and  work  is  underway 
to  include  wind  estimations  into  the  presented  waypoint  genera¬ 
tion  equations.  Moreover,  a  sensitivity  analysis  of  the  uncertainties 
in  parameters  such  as  aircraft  airspeed  and  bank  angles,  is  also 
foreseen.  Besides  that,  we  also  plan  to  close  the  loop  between  the 
Flight  Plan  Manager  and  the  Virtual  Autopilot  so  that  the  former 
will  be  able  to  keep  track  of  the  deviations  from  the  nominal  path 
and  recompute  waypoints  to  adjust  the  trajectory. 
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Appendix  A.  Interception  angle  computation 


length  (L)  and  the  turn  radius  (R)  as: 


For  a  generic  FO+DF  leg,  the  interception  angle  can  be  com¬ 
puted  analytically  after  finding  the  coordinates  of  point  M,  as 
shown  in  Fig.  1(a).  At  this  point,  the  arc  describing  the  turning 
trajectory  that  follows  after  the  FO  waypoint  is  tangential  to  the 
flight  segment  that  directly  leads  to  the  next  waypoint.  Let  ( x ,  y) 
be  the  coordinates  of  this  point  in  a  Cartesian  coordinate  system 
centred,  this  time,  at  the  centre  of  the  arc  (point  C).  Let  (xp,yp) 
be  the  coordinates  of  the  following  waypoint  in  the  flight  plan  list. 
Then,  point  M  coordinates  can  be  found  by  solving  the  following 
two  equation  system: 

ix2  +  y2  =  R2 

]  l  y~yP  =  i  (3) 

[  X  X-Xp 

First  equation  imposes  that  point  M  belongs  to  the  circum¬ 
ference  centred  at  C,  while  second  equation  forces  the  tangency 
condition  with  the  line  that  joins  point  M  with  the  following  way- 
point.  Two  solutions  are  found  for  this  equation  system,  being  one 
of  them  the  coordinates  for  point  M: 


R  /  RyP  +  J  Xp  R2  +  xp  +  j/pXp  \ 

x=-^r+yp — ^ — j 


/  RyP  +  R2  +  *p  +  yjrf,  \ 

=  Ryp(  W+?p  ) 

Furthermore,  the  interception  angle  is  given  by: 


(4) 


/?  =  arctanf- — —  ^  (5) 

V  xP  -  x  J 

and  in  turn,  (xp,  yp)  coordinates  can  be  expressed  as: 


xp  —  L  —  R  sin  \lr  yp  — R  cos  \lr  (6) 

Then,  by  using  Eqs.  (4),  (5)  and  (6),  the  interception  angle  can 
be  expressed  in  function  of  the  course  change  angle  xj/,  the  leg 


L,  R)  =  arctan^-R 

L3c(f)  -  \RL2  s(2f)  -  2R2Lc3(x/s)  +  2  R2Lc(i/r)  -LA  +  RAs(f) 

I4  -  4RL3s(x/r )  -  5R2L2c2(x/r)  +  5 R2L2  +  2^3Ls(^)c2(^)  -  2R3Ls(x/r)  +  R2Ac(x/s) 

(7) 

where  for  the  sake  of  compactness  s(-)  and  c(-)  correspond  to 
sin(-)  and  cos(-)  respectively,  while: 

A  =  VI(2K3s(iA)c2(Vf)  -  2R3s(f) 

-  4RL2s(x/f)  +  L3  -  5R2Lc2(\fr)  +  5 R2L)V2  (8) 
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